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Abstract 

Establishing the absence of deadlocks is important in many applications of formal methods. 
The use of model checking for finding deadlocks in formal models is often limited. In this 
paper we propose a constraint-based approach to finding deadlocks employing the ProB 
constraint solver. We present the general technique, as well as various improvements that 
had to be performed on ProB's Prolog kernel, such as reification of membership and 
arithmetic constraints. This work was guided by an industrial case study, where a team 
from Bosch was modeling a cruise control system. Within this case study, ProB was able 
to quickly find counter examples to very large deadlock-freedom constraints. In the paper, 
we also present other successful applications of this new technique. Experiments using 
SAT and SMT solvers on these constraints were thus far unsuccessful. 

KEYWORDS: Constraints, Formal Methods, Deadlocks, Prolog, Applications. 



1 Introduction 

Formal modelling of discrete event systems is an important tool in order to verify 
their correct functioning. Among others we may want to verify (a) termination of 
certain components, (b) avoidance of unsafe states or (c) absence of deadlocks. In 
the formal models discussed in this article property (|c]), absence of deadlocks, is 
considered the principal property. In fact, in the industrial applications that have 
motivated the work described in this paper the first two properties Q and Q play 
only a small role. 

The classic approach to locating deadlocks is model-checking. Model-checking can 
provide fast feedback, but is also associated with known problems: in many appli- 
cations the state space is either infinite or much too large to explore exhaustively. 
Furthermore, model checking is particularly problematic when the out-degree of 
certain states is very large. 

In this paper we describe a successful application of constraint solving to verify 
absence of deadlocks. In the industrial case study that has started this work, a team 
from Bosch attempts to develop a deadlock-free formal model of a cruise control 
system. For this application, constraint solving typically finds counter examples 



to deadlock-freedom constraints of more than 30 A4 pages in under two seconds, 
while model checking was unsuccessful. It turns out that this approach — on top of 
being much less sensitive to the size of the state space — has additional benefits. It 
exploits safety properties that have been specified (having the positive side effect of 
encouraging their specification) and it can be easily related to verification by formal 
proof. Model-checking can succeed showing absence of deadlocks even if this cannot 
be verified by formal proof using all specified safety properties. Constraint solving 
will only succeed if also a proof can be found: it is not based on model execution. 



In Event-B (Abrial 2010), the formal method we have used in the case studies, this 
helped to achieve a more comprehensive methodology of verification. In the end, 
it is the mix of constraint solving, model checking and proof that advanced the 



case study of Bosch using ProB (Leuschel and Butler 20081 and Rodin (Abrial 



et al. 2010). Rodin is a software tool for formal modelling with Event-B. It is 
equipped with editors, a proof obligation generator and some theorem provers. 
ProB is also available as a plug-in for Rodin providing animation, model-checking 
and constraint-solving facilities. 



1.1 Deadlock- Freedom in Event-B 

We discuss deadlock freedom in terms of Event-B. However, the results are not 
specific to Event-B. The concept of deadlock freedom applies quite universally to 
state-based formal methods. In fact, the corresponding constraint solving technique 
implemented in ProB can be applied immediately to models created using the 



"classical" B-Method (Abrial 1996) and the Z specification notation. 

We only present the concepts of Event-B necessary to discuss deadlock freedom. 
In particular, we ignore concepts such as refinement, theorems or witnesses. An 
Event-B model is called a machine. A simple machine is shown in Figure [T] The 

MACHINE MinSet 
CONSTANTS 

AXIOMS AfCO..3AA^0 
VARIABLES s, mm, z 

INVARIANTS s C . . 3 A min e0..3A2;e0..4 
EVENTS 

INITIALISATION = s := Af U {3} |1 min := 3 || 2 := 4 

acc = ANY X WHEN min & sAxesAx< min THEN s := s — {min} \\ min := x END 
rej = ANY x WHEN min GsAx£sAx> min THEN s : = s - {x} END 
get = WHEN s = THEN z := min END 
END 

Fig. 1. A machine for computing the minimum z of a set s 

state of a machine is described in terms of constants and variables. The possible 
values of the constants are constrained by axioms A = Ai A . . . A and the 
possible values of the variables by invariants I = /i A . . . A /s , all expressed in 
first-order predicate logic augmented with arithmetic over integers and (typed) set 



^ All indices in this paragraph have the range "> 0" . 
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theory. State changes are modelled by events. Each event consists of a collection 
of parameters pi, . . . ,pi, of guards g ~ gi A . . . A gj and of actions a (usually a 
collection of simultaneous update statements ai \\ ... \\ at) {^Guards are predi- 
cates over the constants, variables and parameters. We use the following schema to 
describe events: ANY pi,...,p, WHEN g THEN a END. We leave out clauses of 
an event that are "empty" . For instance, an event without parameters is written 
WHEN g THEN a END; and an event without parameters and guards consists just 
of the actions a. An event needs to be enabled to change the state as described by 
its actions. An event is enabled in a state if there are values pi, . . . ,pi that make 
its guard g true in that state. We denote the enabling predicate {3pi, . . . ,pi-g) of 
an event e by Ge- Being enabled an event can be executed by performing all its 
actions simultaneously. A special event, called the INITIALISATION is executed 
(once) first to initialise the machine. The INITIALISATION event does not have 
guards or parameters. 

1.2 Constraint Solving of Deadlock-Freedom Proof Obligations 

A state of a machine in which none of the events (except for the INITIALISATION 
event) is enabled is called a deadlock. We can search for such states by model 
checking, namely by looking at all the reachable states and enabled events. Another 
approach is to prove absence of deadlocks. The invariant of a machine describes a 
superset of the reachable states]^ So, if the invariant is "precise" enough it should 
imply that always one of the events is enabled. Formally this can be expressed in 
terms of the proof obligation: 

A A / ^ Gei V . . . V Ge„ (DLF) 

where A are the axioms, / are invariants and Ge, {£ & I .. n) the enabling predi- 
cates of the events eg. Counterexamples to the proof obligation can be found using 
constraint solving. 

Now we have three approaches to finding out about deadlocks: model check- 
ing, proof and constraint solving. Often they do not yield the same results. Model 
checking finds only those deadlocks that can actually occur during execution of the 
events. Proof and constraint solving signal deadlocks depending on whether the 
proof obligation holds. If attempting to prove it, we may "get stuck" in a proof. 
This may happen because the proof obligation cannot be proved (i.e. the invariant 
is too weak or the enabling predicates are too strong) or because something is wrong 
with the proof. These two causes are difficult to distinguish for complicated proof 
obligations like the afore-mentioned 30 A4 pages. Constraint solving produces a 
counter example if the implication does not hold. Hence, it helps distinguishing the 
two causes. Although proof applies, in general, to a much larger class of formulas 
(that is, proof obligations) than constraint solving we found that many models we 

^ The exact form of the update statements is not relevant for this article. 
^ This in turn can be verified by model checking or proof. 



3 



encountered use only a restricted class of formulas where constraint solving could 
be applied, too. 

Model checking the Event-B machine of Figure [T] detects a deadlock for the state 
N = ..3 A s — {0} A min = A z = 4: if the set s contains only one element, none 
of the events is enabled. We change the guard of event get to s = {min} to correct 
the problem. Now model checking succeeds - there is no deadlock. However, we 
cannot prove this. Why? The deadlock-freedom proof obligation is the following: 

ArcO..3AiV7^0AsCO..3A min g0..3AzG0..4 

=J> {3x • min GsAx^sAx< min) V 

{3x ■ min €sAx(zsAx> min) W s — {min} 

Constraint checking of the corrected machine yields a deadlock in the state N — 
{3} A s = A min = A z = 0: neither min G s nor s ~ {min} holds in this 
state. Adding min g s to the invariants of the machine solves the problem. We 
have discovered a fact about our model — the minimum to be computed is always 
contained in the set s — and we have specified this fact as an invariant describing 
the reachable states. Doing this kind of analysis exclusively by means of proof on 
large proof obligations can be very difficult. Model checking and constraint solving 
make it practically feasible to analyse such proof obligations. 

Due to the number of constants and variables in realistic models, model checking 
also encounters a number of known problems that can be avoided using constraint 
solving. For instance, there can be a practically infinite number of ways to in- 
stantiate the constants of a B model. In this case, model checking will only find 
deadlocks for the given constants chosen. And the number of choices is exponential 
in the number of constants. Constraint checking proceeds smarter, for instance, by 
propagating constant values (but remains worst-case exponential, of course). 



1.3 Constraint Solving with ProB 



ProB (Leuschel and Butler 2008) is a validation tool for high-level specification 
formalisms, such as the B-Method, Event-B, Z and CSP. ProB provides various 
validation techniques, such as animation, model checking, constraint checking, re- 
finement checking and test-case generation. The various specification formalisms 
are encoded in Prolog in the form of an interpreter, usually encoding an opera- 
tional semantics of the language. For example, CSP is embedded within ProB in 



the form of Roscoe's operational semantics (Roscoe 19991. The foundation of the 
B-Method, Event-B and Z are set theory, (integer) arithmetic and predicate logic. 
As such, ProB provides constraint solving over sets and derived datatypes such as 
relations and functions. 

The basic constraint solving functionality concerns (a) checking for invariant 
preservation by all or by some specific operations, (b) validating data only available 
at deployment time with respect to formal properties used during development 
(c) finding some state satisfying given axioms and invariants and, finally, (d) finding 



a deadlock. The first Q is similar in functionality to Alloy (Jackson 2002) and 



has already been discussed in (Leuschel and Butler 2008). The second (|b]) has been 
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successfully applied by Siemens to analyse railway networks in production ( Leuschel 



et al. 2009). The third icl is useful to check axioms and invariants for contradictions. 



The last ml is described in more detail in this article. In addition to the deadlock 



checking discussed in Section 1.2 a variant is supported by ProB that permits 
specifying a predicate of interest P. Using this we can restrict deadlock checking 
to a subset of states that may provide further insight. For instance, in the example 
discussed above we could have taken P to be min £ s first, in order to see whether 
it is sufficient to achieve deadlock- freedom. 



2 Principles of Constraint-Based Deadlock Checking 

In this section we sketch the algorithm implemented for constraint-based deadlock 
checking in ProB. First we discuss the direct approach that addresses directly 
proof obligation (DLF) by negating the guards (DLN). Based on some criticism of 
the direct approach we finally present the promised algorithm in Section [2. 2[ 



2.1 Direct Approach 

The direct approach is quite simple: construct a formula (DLN) consisting of the 
conjunction of the axioms A of the model, the invariants / of the model and the 
negation of the enabling predicate (^Ge^) for every event of the model. Formally, 

AM A ^Ge, A ... A ^Ge,, (DLN) 

If we find a solution for this formula, then we have found a deadlocking state. 
As discussed in Section |1.2| this state is not necessarily reachable from the initial 
states. However, this state is allowed by the axioms and invariants of the model. 
Any attempt at proving the deadlock-freedom proof obligation (DLF) is guaranteed 
to fail. (The model should thus be corrected, independently of whether this state 
can actually be reached or not.) Note that when the axioms of the model are 
inconsistent, the constraint solver will not be able to find a valid valuation of the 
constants and thus (by monotonicity) also not find a deadlocking state. Consistency 
of the axioms can be checked by ProB, using the technique ([c| of Section 1.3 or 
simply by starting an animation of the model. 

Criticism of the Direct Approach Applying the ProB constraint solver to 
the constraint (DLN) above yields a counter-example to the deadlock-freedom proof 
obligation (DLF) if the constraint (DLN) is satisfiable. However, the above approach 
suffers from a series of shortcomings that restrict its potential use: 

Redundancy. ProB will find values for all variables and constants of the 
model. However, it is quite common that some of the variables and constants are 
not relevant for the guards of the events (e.g., they are only used in the action parts 
or are sometimes only there for helping with the proof effort but do not affect the 
behaviour of the model). For example, in the machine of Figure [l] variable z is not 
relevant for the guards. 

Solution. To solve this we partition the formula into connected sub-components. 
We can ignore any sub-component not related to any guard. 
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Inaccuracy. Sometimes the user is not interested in arbitrary deadlocks, but 
only in a certain class of deadlocks. For example, in when analysing the machine of 
Figure[l]we may only be interested in looking for deadlocks in states where min E s. 
Solution. To address this requirement, we give the user the possibility to specify 
an additional predicate P of interest. This predicate is added to the constraints 
to be solved. In addition, we optionally filter out any event that can obviously 
not fire given P; for example, any event that has Counter=5 in its guard given 
P = Counter=10. This obviously simplifies the constraint to be solved, and more 
importantly, can sometimes result in a much better decomposition of the formula 
into independent sub-components. 

Inefficiency. Formulas may not directly fit shapes that can be treated effi- 
ciently by the constraint solver. For instance, the use of the existential quantifiers 
in enabling predicates complicate the constraint solving process. Indeed, the ProB 
kernel will usually wait until all quantities used inside the existential quantifier are 
known before evaluating it; see Section [3] 

Solution. To solve this we run a simplifier on the enabling predicates before adding 
them to the constraint store. For example, the predicate 3x ■ min E sAx E s can be 
simplified to min e s A (3a; ■ x £ s) and further to min £ s As ^ 0. Comparing this 
to the machine of Figure [l] one can see that simplification will often not produce 
rewritings to this degree. However, in the case studies described later it was very 
effective. Currently, the simplification process is straightforward, mainly addressing 
common patterns that appear in guards, such as: 

• 3x.x G S* is simplified to 0; 

• 7^ is simplified to TRUE, in case S is guaranteed to be non-empty; 

• 3x.x > E is simplified to TRUE; 

• 3x.{x ^ E A P) is simplified to P[E/x]. 

A couple of simplifications have been implemented in Prolog. Outside of ProB we 
have also experimented with good results with the simplifier of the theorem prover 



Isabelle ( Paulson 1994 1 that has a large number of simplifications that come with its 
theories of set theory and arithmetic. Because in our methodology theorem proving 
already plays an essential role, we could reuse a simplification already implemented. 
Integration with theorem prover looks like a promising option for the future. 



2.2 Improved (More Efficient) Algorithm 

The discussion of Section [2?T] suggests the improved algorithm for deadlock checking 
shown in Fig. [2j the algorithm implemented in the current version of ProB (1.3.3): 
The problem of redundancy is addressed by the partitioning in linc |13[ the problem 
of inaccuracy by the incorporation of the predicate of interest; and the problem of 
inefficiency by the invocation of the simplifier in line [6) Note that the latter two 
techniques are orthogonal to the algorithm and could be applied to other constraint 
checking problems in the same way. Finally, in line [13] we can optionally remove all 
components Cj not relevant for the deadlock. 
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1: input: predicate P of interest, list L of events of interest 

2: AI := A A 7 A P; (* axioms, invariants and predicate of interest *) 

3: Deadlock := TRUE; (* only relevant enabling predicates are considered *) 

4: for each event e in L do: 

5: extract enabling predicate Ge of event e; 

6: simplify Ge; (* as described above *) 

7: if solve(AI A Ge) 7^ false then 

8: (* otherwise the event is always disabled given P *) 

9: Deadlock ~ Deadlock A ^(Ge) 

10: fi 
11: od 

12: sort conjuncts nested inside Deadlock (move most-used conjuncts to the front) 
13: (Gi, . . . , Cn) '■= components(AI A Deadlock); 
14: return {solve(Gi),. . . ,solve(Gn)) 



Fig. 2. Improved algorithm for deadlock checking 



3 Core of the ProB Constraint Solver 

In this section we present some key aspects of the ProB constraint solver and its 
implementation in Prolog. We pay particular attention to the extensions that were 
made in light of the Bosch application (Section [4]). 



3. 1 Overview 

The ProB kernel provides a constraint-solver for the basic datatypes of B (and 
Z) and the various operations on it. As such, it supports booleans, integers, user- 
defined base types, pairs, records and inductively: sets, relations, functions and se- 
quences. These datatypes and operations are embedded inside B (and Z) predicates, 
which can make use of the usual connectives (A, V, =>, <J^, -1) and typed universal 
{\/x.P Q) and existential {3x.P A Q) quantification. 

ProB integrates various constraint solvers in its kernel: 
• Integers are represented using Prolog integers. To implement arithmetic con- 



straints, ProB uses the SICStus CLP(FD) finite-domain library (Carlsson and 



Ottosson 1997) 



Elements of basic sets are represented internally as terms of the form fd(Nr,T), 
where T is the type name and Nr is the number of the element. Equality is then 
implemented simply using unification. Disequality is generally implemented using 
the disequality operator of CLP(FD). Thus, disequality can also sometimes deter- 
ministically instantiate its arguments. E.g., given the user-defined type S={a,b}, 
the predicate x /= a will force the value of x to be b. 

The constraints for the more complicated types have been written in Prolog with 
co-routines. Note that ProB employs various set-representations: AVL-trees for 
fully known sets (to be able to deal with large sets arising in industrial applica- 



tions, cf. (Leuschel et al. 2009)), closures to represent certain sets symbolically 
and Prolog lists for partially known sets. A feature that distinguishes ProB is 
that it not only deals with simple sets, but also allows sets of sets, relations, etc. 
Generally, co-routines are used to block non-deterministic computations. A non- 
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deterministic computation provides an estimate of the number of solutions to the 
ProB waitflags store and obtains a Prolog variable on which it can block (called 
a waitflag). This waitflag will be instantiated by the enumeration process, which 
will unblock computations with the least number of solutions first and will also 
take care of labeling the CLP(FD) variables. 
• Finally, the boolean predicate solver is also written in Prolog using co-routines. 
We describe some aspects of its implementation in more detail below. We did 
not reuse the SICStus boolean constraint solver mainly due to the treatment of 
undefined predicates and in order to link the labeling with our other solvers. 



3.2 Challenges in Reusing CLP(FD) 

Initially ProB did not use CLP(FD): up until version 4.0.8, SICS advised against 
combining co-routines and CLP(FD) in the same program. With the arrival of 
SICStus 4.1, we started to integrate CLP(FD) into the ProB kernel. Still, we 
encountered segmentation faults in the first versions (SICStus 4.1.1). These issues 
have been fixed in 4.1.2. 

In B and Z, integers are unbounded but B also provides the implementable in- 
tegers, which in typical industrial applications fall in the range —2^^ .. 2^^ — 1. 
Unfortunately, the CLP(FD) library by SICStus can only represent integers from 
228 _ — 1 in 32-bit mode. Hence, ProB always has a Prolog "backup" solution 
(without interval propagation) available and tries to catch overflows when posting 
CLP(FD) constraints. Still, overflows can happen outside of the control of the ker- 
nel, simply by instantiating a variable. Hence, ProB can also be run completely 
without CLP(FD). Another solution is using the 64-bit version of SICStus Prolog, 
where we can handle integers in the range —2^" .. 2^" — 1. 

Difficulties arise when the models contain unbounded mathematical integers. In 
the Bosch application, we have several mathematical integers (e.g., to represent 
time) and the constraint solver may be asked to solve a constraint x>y and y>=x. 
This situation actually arises very frequently in constraint-based deadlock check- 
ing, when events have common guards or complementary guards. Unfortunately, 
CLP(FD) does not deal very well with such constraints. First, it does not detect an 
inconsistency after posting X#>Y,Y#>=X. Second, if we later add another constraint, 
such as Y#>200 we get an integer overflow error Our solution is to add a time-out 
when posting constraints, and revert to the Prolog backup if a time-out occurs. Fur- 
thermore, we have extended our boolean constraint solver to detect identical atomic 
predicates. Basically, every atomic predicate is normalised and then checked if it 
occurs at another place in the same formula: if it does, the predicate is evaluated 
only once. As a special case, it detects the inconsistency above. 



Finally, CLP(FD) does not deal with undefinedness (Frisch and Stuckey 2009) 
the same way that B does : X in 1 . . 10, X/0#=10 simply fails, while in B this is 
an erroneous formula. ProB tries to catch those errors. This is reflected inside the 



Using the hardware configuration of Section |4] this happens after about 40 seconds. 
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b_check_boolean_expression2 (equivalence (LHS.RHS) , _ , LState , State ,WF, Res ,Ai ,Ao) : - ! , 
equiv(LR,RR>Res) , 

b_check_booleaii_expression(LHS , LState , State ,WF,LR,Ai ,Aii) , 
b_check_booleaii_expression(RHS , LState , State ,WF,RR.Aii , Ao) . 
:- block equiv(-,-,-) . 
equiv(X, Y,Res) :- 

( X==pred_f alse -> negate(Y,Res) ; X==pred_true -> Res=Y 
; Y==pred_true -> Res=X ; Y==pred_f alse -> iiegate(X,Res) 

; Res==pred_true -> X=Y ; Res==pred_f alse -> negate(X,Y) 

; add_error_f ail (equiv, ' Illegal values: ' ,equiv(X, Y.Res) ) 
). 

:- block negate (-,-) . 
negate(pred_true,pred_f alse) . 
negate(pred_f alse,pred_true) . 

Fig. 3. Implementation of the Equivalence Connective in ProB 

boolean constraint solver and the fact that we do not yet use CLP(FD) for division 
and modulo. 

3.3 The ProB Boolean Constraint Solver 

The boolean constraint solver uses reifications of the basic atomic predicates to 
communicate with the other solvers. More precisely, given a basic atomic predicate 
P, we associate with it a Prolog variable i?p. If another solver can determine that 
P must be true, then it sets Rp to pred_true. If it can determine that P must 
be false, then it sets Rp to pred_f alse. Similarly, if Rp is set to pred_true (resp. 
pred_f alse) by the boolean constraint solver, the other solver should add P (resp. 
-^P) to its constraint store. 

The boolean constraint solver also uses reification internally to treat more com- 
plex subformulas. Figure [3] shows, e.g., how the equivalence connective is imple- 
mented inside the b_check_booleaii_expression2 predicate. The variable LR is the 
reification of the left-hand side predicate LHS. Similarly, RR is the reification of 
the right-hand side predicate RHS. Finally, Res is the reification of the equivalence 
LHS <=> RHS. The equiv procedure will ensure consistency of the three reifica- 
tion states and ensure propagation of information: it blocks until at least one of 
the reification variables is instantiated and then propagates the information, pos- 
sibly using the auxiliary negate procedure. For example, if Res and LR are known 
to be false (pred_f alse), then LL will be forced to pred_truej^ This will trig- 
ger further information propagation inside the call b_check_boolean_expression 
for LHS. E.g., if LHS is x=2 then the Prolog variable representing the B identifier 
X would be forced to 2 (actually int(2)). The code for the other connectives in 
b_check_booleaii_expression2 is a bit more complicated, due to the treatment of 
undefinedness. 

ProB does not yet provide reifications for all atomic predicates. E.g., the subset 

^ In ProB 1.3.4 we have introduced a more refined implementation of negate using attributed 
variables. It will, e.g., infer from negate(X,Y) ,negate(Y,Z) that X==Z. 
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t^(X6{e,l,2} A z^ajMisA) A -^2 A ysA) A ^|yi-A)|| True] ^ 



f-(xe{e,l,2} A z<e A ysAl] ! ''''""^ ^(x>2 A ysA)"] ] True^ [H^^IlCEmi^ 

|(X6{0,1,2} A z*B y6A)| | False^ |(x>2 A y6fl)|| False^ |(yeAT]| False} ^ 



Reification 



Fig. 4. Illustrating the ProB Boolean Constraint Solver and the importance of 
Reification (given invariant a; > 0) 



relation C is not yet reified. However, all basic predicates that appear in the Bosch 
application have been reified, in particular: 

• E Cz P; there are optimized reifications available for x € {Ci, . . . , C„} where 
Ci, . . . , C„ belong to an enumerated set or are integers, 

• El — E2, El 7^ £'2, and Ei □ E2 where □ is one of <, >, >, <, 

• Universal and existential quantifiers with small scope, which are expanded 
into conjunctions and disjunctions respectively. 

Example 3.1 

Figure |4] shows a small example, which is inspired by the deadlock constraint of 
the Bosch case study. In step 1, we start by asserting that the top-level formula 
^{x e {0, 1, 2} A z 7^ A y e ^) A ^{x > 2Ay e A) A ^{y ^ A) is true. We assume 
that an invariant x > has already been asserted. In steps 2, 4, 6, we then assert 
that all three sub-conjuncts must themselves be true. In Steps 3, 5, 7 we deal with 
the negation. Note that at step 7, we assert that y ^ A \s false. Due to predicate 
sharing, this immediately triggers that y ^ A must be true, thus forcing x > 2 to 
be false in step 9. At step 10, reification comes into play. Here, given the invariant 
X > 0, the ProB solver infers that a; € {0, 1, 2} is true, which then forces 2; 7^ to 
be false. In summary, the ProB kernel finds the solution z — Q deterministically 
without enumeration. 



4 Case Studies 

All experiments were run on a MacBook Pro with a 3.06 GHz Corc2 Duo processor, 
ProB 1.3.3 compiled with the 32-bit version of SICStus 4.1.3. 

Standard Benchmarks Figure [5] shows that the constraint-based deadlock 
checker (CBC) is capable of quickly finding deadlocks for a variety of B models 



(mainly taken from ( Bendisposto and Leuschel 2009 ) ; more details about the mod 



els can be found in that paper). mondex_m2 is the second refinement of a model 
of the Mondex Electronic Purse; it contains 5 constants, 10 variables and 6 events. 
CXCCO is a model of a congestion control protocol with 6 constants, 8 axioms. 
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Model 


CBC (s) 


Result 


MC (s) 


Result 


CXCCO 


0.00 


deadlock 


0.01 


deadlock 


earley_2 


0.01 


deadlock 


403.68 


no deadlock found * 


earley_3 


0.01 


deadlock 


0.14 


deadlock 


Eco_Mch_4 


0.02 


deadlock 


580.28 


no deadlock found** 


FMCH02 (1) 


0.00 


deadlock 


0.01 


deadlock 


FMCH02 (2) 


0.53 


no deadlock 


0.13 


no deadlock 


mondex_m2 


0.00 


deadlock 


0.01 


deadlock 


platoonl 


0.01 


deadlock 


0.00 


deadlock 


platoon2 


0.06 


deadlock 


0.03 


deadlock 


scheduler (2) 


0.00 


no deadlock 


0.00 


no deadlock 


scheduler (5) 


0.00 


no deadlock 


0.49 


no deadlock 


scheduler (9) 


0.00 


no deadlock 


107.18 


no deadlock*** 


Siemens 


0.00 


no deadlock 


211.28 


no deadlock** 


Volvo 


0.20 


no deadlock 


5.16 


no deadlock 



*: no deadlock found after visiting 10,000 states. 
**: no deadlock found after visiting 100,000 states; the system is infinite state. 

with hash symmetry it only takes 0.120 s to model check the system. 



Fig. 5. Constraint-Based Deadlock Checking (CBC) vs Model Checking (MC) 



5 variables, 20 invariants and 3 events. The Siemens model is a specification of a 
fault-tolerant automatic train protection system, with 15 variables, 28 invariants 
and 10 events. The model has an unbounded time variable and is hence infinite 
state. earley_2 is the third refinement of a model of the Barley parsing algorithm as 
developed by Abrial. It contains 6 constants, 18 axioms, 5 variables, 7 invariants, 
and 4 complicated events. earley_3 is the fourth refinement of the same model, pla- 
toonl and platoon2 are refinement levels of a platooning system by Mashkoor and 
Jacquot. The second refinement contains 11 constants, 18 axioms, 4 variables, 6 
invariants and 7 events. FMCH02 is the second refinement of a file system model 
with 6 constants, 8 axioms, 7 variables, 12 invariants, and 9 events. We examine 
the system with carrier set sizes 1 and 2. scheduler is an Event-B translation of 
the scheduler from (Legeard et al. 2002), for a varying number of processes. Volvo 



is the (B-Method) model of a vehicle function described in (Leuschel and Butler 



2008), containing 15 variables and 26 events. 



Evolution: A BPEL Development We now go into more detail for one case 
study, a business process for a purchase order. The Event-B model is obtained 
via an automatic translation from BPEL (Ai't-Sadoune and Ameur 2009). Initially 
the model was believed to be free of deadlocks. However, ProB managed to find 
a deadlock and it took 5 iterations to finally obtain a deadlock free version of the 
business process. The last model has 15 events with 59 guards. Note that the model 
has also driven the development of the constraint-solver; initially ProB was unable 
to quickly find a deadlock for the fifth version of the model. This helped uncover 
an inefficiency in ProB's constraint solver. After solving it, ProB now finds the 
deadlock almost instantaneously for the first five models (see Figure [6]). Finally, for 
the sixth model, ProB confirms that no counter example exists for default deferred 
set sizes 1,2,3. 

One can see in Figure |6] that the constraint checking time increases as the model 
evolves: as the model is improved, deadlocks get harder and harder to find. (It is 
interesting that deadlock freedom of the fifth model was proved; however, it turned 
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Version 


CBC (s) 


Result 


MC (s) 


Result 


BPEL vl 


0.05 


deadlock 




no INITIALISATION 


BPEL v2 


0.05 


deadlock 


0.09 


deadlock 


BPEL v3 


0.04 


deadlock 


0.09 


deadlock 


BPEL v4 


0.03 


deadlock 


0.09 


deadlock 


BPEL v5 


0.13 


deadlock 


5.62 


no error found*(10) 








140.82 


no error found*(100) 








1423.56 


no error found*(1000) 


BPEL v6 


0.37 


no deadlock 


5.61 


no error found*(10) 








140.89 


no error found*(100) 



*(X): not all transitions computed; maximum out-dcgrcc X 



Fig. 6. Comparing Constraint-Based Deadlock Checking (CBC) and Model Check- 
ing (MC) on multiple versions of the same model 



out that a wrong proof obligation was generated.) In the first four models the model 
checker manages to find deadlocks also very quickly. However, starting with the fifth 
version, the model checker is no longer able to provide interesting feedback. The 
out-degree for the initialisation and constant setup is just too big. 

The Bosch Cruise Control AppHcation The main motivation for this work 
was the deadlock checking for a cruise control system modelled by Bosch within the 
Deploy project. Indeed, proving absence of deadlocks is crucial in this case study 
(Loesch et al. 2010), as it means that the engineers have thought of every possible 
scenario. In other words, a deadlock means that the system can be in a state for 
which no action was foreseen by the engineers. 

The model contains many levels of refinement and the particular machine of 
interest is very big: it contains 78 constants with 121 axioms, 62 variables with 
59 invariants and has 80 events with 855 guards (39 of them are disjunctions, 
containing 17 more conjuncts nested inside). Of the 140 variables and constants, 4 
have 2^^ = 8,192 possible values, 11 have 2^^ possible values, one has 2^^, another 
one has 2^^, and 79 variables or constants have infinitely many possible values 
(or so many that they cannot be represented as a floating number). The resulting 
deadlock-freedom proof obligation is very big: when printed it takes 34 pages of 
A4 using 9-point Courier. Initially, the Rodin toolset also had trouble loading this 
proof obligation resulting in a "Java Heap Space Error". Furthermore, even after 
successfully loading the proof obligation into the Rodin proving environment, it is 
very tedious for a user to try discharging the proof obligation and the information 
obtained from the failed proof attempt is not very useful. 

Here ProB's constraint-checking feedback has been very valuable: it provides the 
Bosch engineers with a concrete scenario which has not yet been anticipated and 
allows them to modify the model accordingly. ProB can then be run again on the 
modified model, until no more deadlock can be found. One can then switch to the 
Rodin provers to discharge the proof obligation. (For a smaller version of the model 
this was actually very successful: the newPP prover was then able to automatically 
discharge the proof obligation). 

The latest version of ProB takes from 1.07 to 2.32 seconds for finding dead- 
locks for various versions of the Bosch model for a particular predicate of interest 
(Counter=10). Also note that loading and type checking the model takes a consider- 
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able amount of time. For example, the Prolog representation of the abstract syntax 
tree takes about 7.5 MB on disk. The total time for finding a deadlock, including 
loading, type- checking, building the constraint and constraint solving, hence takes 
from 9.98 to 11.92 seconds. 

Note that model checking of these models was not really successful. E.g., for the 
latest version of the model the model checker requires 50.41 seconds in total to find 
a deadlock. Unfortunately, this is not a deadlock that is of interest to the Bosch 
engineers (we have Counter=l for the deadlock state). When searching specifically 
for deadlocks with Counter=10, the model checker failed to find a counter example 
after running for almost 4 hours (with a maximum out-degree of 20). 

In summary, the result of this case study has been very encouraging. We have 
managed to solve big deadlock constraints of a real industrial application. The 
obtained deadlock counter examples have been extremely useful to the engineers, 
helping them to improve the model. 



5 Related Work and Conclusion 



As far as constraint solving for sets is concerned we would like to mention setlog 



(Dovier et al. 2000 1, which is unfortunately no longer maintained. Setlog has certain 



restrictions (e.g., interval bounds must be known values, x £ y..6 is not accepted) 
and does not seem to cater for reification, which we used for effective integration into 
a boolean constraint solver. We conducted one comparison, solving the N-Queens 
problem for n = 14: setlog 4.6.14 took about 40 seconds to find the first solution. 



compared with 0.03 seconds for ProB. Another tool of interest is BZ-TT (Legeard 



et al. 2002). This tool can also be used for constraint solving, and has been used for 



test-case generation, but its support for B quite limited (e.g., it does not support 
set comprehensions nor refinement). Also, we were unable to load and solve the 
BPEL deadlock constraints (Sect. |4]) nor solve an N-Queens puzzle with BZ-TT. 
Two more animation tools for B are AnimB and Brama. As we have shown in 



( Leuschel et al. 2009 ) , none of them are capable of dealing with more sophisticated 



constraints. The same is true of the TLC model checker ( Yu et al. 1999 ) for TLA 



Alloy ( Jackson 2002 ) on the other hand can be used for constraint solving and has 



been used in at least one instance for deadlock checking ( Dillon et al. 2006 1 



Our deadlock constraint (DLN) is often already very close to being in conjunctive 
normal form (CNF). As such, one may wonder whether SAT or SMT technology 
could have been employed for our application. 



SAT In (Howe and King 2010 ) Howe and King present a Prolog SAT solver which 



uses co-routines to implement unit propagation efficiently and elegantly. The ProB 
boolean constraint solver also achieves unit-propagation, but is not optimized for 
CNF. In particular, ProB creates a variable for every subformula and attaches 



co-routines to it, whereas (Howe and King 2010) uses a clever scheme tailored for 



CNF to wait only on two variables per clause. Still, ProB can solve some non- 
trivial SAT problems when encoded in B. E.g., for the most complicated SATLIB 
example in ( Howe and King 2010| ) (flat200-90 with 600 Boolean variables and 2237 
Clauses) ProB takes 3.27 seconds to find the first solution (successive solutions 
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are then found very quickly). The Prolog SAT solver from (Howe and King 2010) 



takes only 0.13 seconds to solve this example and minisat (Een and Sorensson 



2003) is even faster (about 0.01 seconds)]^ Still, ProB is working directly on a 



high-level formalism: for the usual applications of ProB, the number of clauses is 
much smaller than for SAT encodings. ProB also has to deal with issues such as 
potentially undefined expressions, which leads to performance penalties and makes a 
CNF encoding less appealing. Granted, better encodings are available to solve pure 
SAT problems, but in the setting of B and Z it is unclear whether an approach such 
as (Howe and King 2010) would pay off. 

SMT Compared to SMT solving our constraint-solving approach uses static or- 
dering and is capable of theory propagation via reification (see Example 3.11, but 
is lacking one important feature: clause learning. However, to apply SMT solvers 
to our deadlock formulas we need support for set theory, relations and functions. 
Such support is not yet openly available. The company Systerel is currently devel- 
oping a translator from B to SMTLIB based on ( Deharbe 2010[ ). We have used a 
beta version of the translator on the BPEL examples from Sect [3] Unfortunately, 
we were not able to use the VeriT SMT solver due to a bug in the translator. We 
were able to run CVC3-2.2 on the deadlock constraint of v4: it ran for 30 seconds 
without displaying a result, after which the Rodin time-out aborted the process. 
Note that ProB takes 0.03 seconds to find a counter example. So far we have also 
not been able to use Kodkod ( Torlak and Jackson 2007 ) high-level interface to SAT 
(used by Alloy) to solve the deadlock constraints for this example. Nonetheless, we 
are still investigating this research avenue further. 

In conclusion, we have presented a way to validate deadlock freedom of B and 
Event-B models using a constraint-solving approach. We have shown an algorithm 
for constraint-based deadlock checking and believe further significant will be possi- 
ble by combining constraint-solving with theorem proving. We have compared the 
approach with model checking. The implementation of the ProB constraint solver 
has been presented and its performance has been evaluated on a series of bench- 
marks and one industrial application. Summing up, the ProB constraint solver 
written in Prolog manages to solve very large deadlock constraints in practical 
examples. The feedback obtained by our new technique has been very useful to 
engineers. Thus far, we have been unable to apply SAT, SMT or model checking 
technology on the industrial application. 
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